Formalism, technique and rigour in Use Case Modelling

In this paper I distil some of my experience in requirements engineering and use case modelling, then list some of the issues (both those I see and those that have been presented by others), together with some suggested resolutions and ways forward. This is not an academic paper it contains few references, and there is no quest for novelty. My interest is in capturing and formulating good practice, and stimulating discussion, in order to assist practitioners. This does not preclude theory; quite the contrary “There is nothing so useful as a good theory.” (Lewin 1951). Note that although we talk of requirements, a use case model is in fact a specification at some level of detail and accuracy. And although we talk of analysis, in fact synthesis is the key co-creating a specification that satisfies the client's requirements. My detailed experience is generally of rather conservative projects iterative and incremental, but somehow subject to a pull (often from the client) to somewhat waterfall and artefact-heavy processes. This is permitted, but not forced, by my proposals in the paper. I'd like to be clearer on the distinction between technique and formalism, though I'm not sure there is a clean border there. In this paper I present my approach rather definitely, but of course I will discuss and improve any of the points I give.